refactor: input note authentication deduced by client #1624

juan518munoz · 2025-12-18T21:10:58Z

Replace logic for adding authenticated input notes in a Transaction. User no longer provides the NoteIDs of the authenticated note he wants to use, but rather send the Note directly (being authenticated or not), and let the Client decide if the note passed is verified.

Note: most test cases have a new step when building transaction requests with authenticated notes. Instead of submitting the transaction with the noteID, they retrieve the associated note with it from the Client, and submit the tx with that info.

Closes #1112

juan518munoz · 2025-12-19T14:52:39Z

crates/testing/miden-client-tests/src/tests.rs

-    // Check that adding an authenticated note that is not tracked by the client will return an
-    // error
-    let missing_authenticated_note_tx_request = TransactionRequestBuilder::new()
-        .build_consume_notes(vec![NoteId::from_raw(EMPTY_WORD)])
-        .unwrap();
-    let error =
-        Box::pin(client.submit_new_transaction(wallet.id(), missing_authenticated_note_tx_request))
-            .await
-            .unwrap_err();
-
-    assert!(matches!(
-        error,
-        ClientError::TransactionRequestError(
-            TransactionRequestError::MissingAuthenticatedInputNote(_)
-        )
-    ));


No longer errors if the Note passed is not authenticated, It will just not get marked as such (by the Client).

SantiagoPittella · 2025-12-19T20:54:19Z

crates/rust-client/src/transaction/mod.rs

+        authenticated_note_records.retain(|note| {
+            matches!(
+                note.state(),
+                InputNoteState::Committed(_)
+                    | InputNoteState::ConsumedAuthenticatedLocal(_)
+                    | InputNoteState::ConsumedExternal(_)
+            )
+        });
+
+        let authenticated_note_ids =
+            authenticated_note_records.iter().map(InputNoteRecord::id).collect::<Vec<_>>();


this two steps can probably be done altogether

I keep them apart as both authenticated_note_records and authenticated_note_ids are used separately afterwards.

SantiagoPittella · 2025-12-19T20:55:34Z

crates/rust-client/src/transaction/mod.rs

+            .filter_map(|note| {
+                if transaction_request.input_notes().iter().any(|n| n.id() == note.id()) {


how are we excluding unauthenticated ones here?

we weren't, good catch, addressed in a9e5113

igamigo

Overall looks good, but I think we should tweak some things before merging. Specifically, unless I'm missing something, it looks like we are adding all notes as InputNote::Unauthenticated and we should probably make the distinction before passing the notes to the VM before executing. I left a comment about this, and some other nits as well.

One thing that would be pending for this PR is the last bullet point in the issue, but maybe that's something to tackle in a different issue/PR

bin/integration-tests/src/tests/swap_transaction.rs

crates/rust-client/src/transaction/request/builder.rs

igamigo · 2025-12-26T19:06:13Z

crates/rust-client/src/transaction/request/builder.rs

+    /// Optional arguments of the Notes to be consumed by the transaction. This
    /// includes both authenticated and unauthenticated notes.
-    input_notes: Vec<(NoteId, Option<NoteArgs>)>,
+    input_notes_args: Vec<(NoteId, Option<NoteArgs>)>,


Related to the comment above, should this just be input_notes_args: Vec<(Note, Option<NoteArgs>)>? Instead of having the extra level of indirection.

extra level of indirection

Thought about that, I believe the best approach is to merge input_notes and input_notes_args into a single field (input_notes). Should we go with it?

crates/rust-client/src/transaction/request/builder.rs

igamigo · 2025-12-26T19:09:45Z

crates/rust-client/src/transaction/request/mod.rs

+    /// Notes to be consumed by the transaction.
    /// includes both authenticated and unauthenticated notes.


We should clarify here (and in TransactionRequestBuilder) this new behavior about the client consuming a note as unauthenticated when it's not present in the store and as authenticated when it is present.

Addressed in 8db0e04

crates/rust-client/src/transaction/mod.rs

CHANGELOG.md

igamigo · 2025-12-26T21:34:01Z

crates/rust-client/src/transaction/request/mod.rs

    /// specified authenticated notes need to be provided, otherwise an error will be returned.
    /// The transaction input notes will include both authenticated and unauthenticated notes in the
    /// order they were provided in the transaction request.
    pub(crate) fn build_input_notes(


We should update this function's doc comments

BTW, I think this can be a private function

BTW, I think this can be a private function

The function is called from impl Client<AUTH> if I'm not mistaken, so it needs to be at least pub(crate).

We should update this function's doc comments

I don't see which part of the docs needs changing, it still only takes authenticated notes as InputNoteRecords.

igamigo · 2025-12-26T21:38:35Z

crates/rust-client/src/transaction/mod.rs

+        let mut authenticated_note_records = self
            .store
-            .get_input_notes(NoteFilter::List(authenticated_input_note_ids))
+            .get_input_notes(NoteFilter::List(transaction_request.get_input_note_ids()))


There's no need to retrieve the full NoteRecord objects here, right? Let's add a TODO (or if you prefer, an issue) to see whether we should add a specific store method to return authenticated note IDs from a set of notes.

As you point out, it's quite redundant to retrieve all notes, as we already pass them as arguments. On the other hand, we need to check that the notes are not consumed and also filter as authenticated, AFAIK this can only be done through the InputNoteRecord struct.

Am I missing something?

igamigo · 2025-12-26T21:44:08Z

crates/rust-client/src/transaction/request/mod.rs

        // Add unauthenticated input notes to the input notes map.
-        for unauthenticated_input_notes in &self.unauthenticated_input_notes {
+        for unauthenticated_input_notes in &self.input_notes {
            input_notes.insert(
                unauthenticated_input_notes.id(),
                InputNote::Unauthenticated {
                    note: unauthenticated_input_notes.clone(),
                },
            );
        }


Does this not add all authenticated notes as well? If so, we should make it so that authenticated notes are consumed exclusively as that instead of added as InputNote::Unauthenticated.

Good catch, addressed in 8db0e04

crates/rust-client/src/transaction/request/mod.rs

igamigo

LGTM! Left a couple of comments but it's good to merge already

crates/rust-client/src/transaction/mod.rs

igamigo · 2026-01-13T19:04:14Z

Pushed a commit that addresses my above comments

refactor: transaction builder only takes one type of note

8ad3365

juan518munoz changed the title ~~refactor: input not authentication deduced by client~~ refactor: input note authentication deduced by client Dec 19, 2025

docs: run typedoc / update markdown files

1925d41

juan518munoz marked this pull request as ready for review December 19, 2025 14:27

chore: address pending TODOs

ae4110d

juan518munoz commented Dec 19, 2025

View reviewed changes

Merge branch 'next' into jmunoz-simplify-transaction-builder-note-inputs

3e3feca

SantiagoPittella reviewed Dec 19, 2025

View reviewed changes

chore: address PR comment

a9e5113

SantiagoPittella approved these changes Dec 23, 2025

View reviewed changes

Merge branch 'next' into jmunoz-simplify-transaction-builder-note-inputs

fb7b469

SantiagoPittella requested review from fkrause98 and igamigo December 23, 2025 18:51

igamigo requested changes Dec 26, 2025

View reviewed changes

juan518munoz and others added 6 commits December 27, 2025 09:36

chore: rename variable

2b9bc78

chore: address PR comments

8db0e04

Merge branch 'next' into jmunoz-simplify-transaction-builder-note-inputs

4f4a2f5

Merge branch 'next' into jmunoz-simplify-transaction-builder-note-inputs

c655226

Merge branch 'next' into jmunoz-simplify-transaction-builder-note-inputs

3873f12

fix: pase notes to build_consume_notes

c07e634

fkrause98 reviewed Jan 9, 2026

View reviewed changes

crates/rust-client/src/transaction/request/mod.rs Outdated Show resolved Hide resolved

review: avoid clone

9901b04

fkrause98 approved these changes Jan 12, 2026

View reviewed changes

SantiagoPittella requested a review from igamigo January 12, 2026 17:52

igamigo approved these changes Jan 13, 2026

View reviewed changes

crates/rust-client/src/transaction/mod.rs Outdated Show resolved Hide resolved

crates/rust-client/src/transaction/mod.rs Outdated Show resolved Hide resolved

reviews: simplify function, expand comments, rename vars

7cb0b97

igamigo added 2 commits January 13, 2026 16:09

reviews: docs

00cc4b5

chore: more simplifications

dfb8525

igamigo merged commit 41807e5 into next Jan 13, 2026
29 checks passed

igamigo deleted the jmunoz-simplify-transaction-builder-note-inputs branch January 13, 2026 20:17

		.filter_map(\|note\| {
		if transaction_request.input_notes().iter().any(\|n\| n.id() == note.id()) {

		/// Notes to be consumed by the transaction.
		/// includes both authenticated and unauthenticated notes.

refactor: input note authentication deduced by client #1624

refactor: input note authentication deduced by client #1624

Uh oh!

Conversation

juan518munoz commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

juan518munoz Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

igamigo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

juan518munoz Dec 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

igamigo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

igamigo commented Jan 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

juan518munoz commented Dec 18, 2025 •

edited

Loading

juan518munoz Dec 19, 2025 •

edited

Loading

juan518munoz Dec 27, 2025 •

edited

Loading